The DNS system utilizes a hierarchical structure to associate fully qualified domain names to a particular IP address in response to a DNS query. For example, if a user visits the website www.example.com on their computer's Internet browser, typically, the stub resolver on the computer would (1) first check its own DNS cache for a suitable response; (2) if not available in cache, query a recursive name server or possibly each level of the delegation graph from the root DNS server downward with the same information, expecting a reply. If the queried system has the information or is authoritative for the precise question, it provides a response or error. If it does not but knows who is, it provides a delegation/referral to the child that should have more precise information. To leverage larger caching mechanisms, a DNS resolver (recursive name server) may be used between steps (1) and (2). Because a DNS resolver services many users, it typically holds a larger cache, helping to reduce the load on root servers and registry servers and often minimize response times for users because it is commonly topologically closer to the client. A DNS resolver may also act as a recursive name server, handling the multiple transactions and following delegations/referral chains between different name servers to resolve the final IP address for the resource in question, simply passing the final answer back to the user's computer. A DNS resolver may ultimately provide in its response a network layer identifier or service location id, which in some instances may be the same.
Some DNS servers support basic filtering of DNS queries based on the source IP address of the original querying machine. For example, some servers may compare the source IP address to whitelists or blacklists of IP addresses and allow or disallow the IP address accordingly. Other servers may use the source IP address to approximate the location (geolocation) of the query source machine, and use this location information to customize the response by returning an IP address of a resource server that is thought to be closer in proximity than another. In all of these cases, generally, once the response is allowed, the DNS response returns the IP address (or network layer identifier or service location id) of a machine that will provide access to the resource server. This IP address, the network layer identifier and service location id, is resolved regardless of the status of the user's permission to ultimately use the resource.
For example, suppose user visited a web site with a customized portal on it, such as mypage.example.com. If the user does not have a valid account with mypage.example.com, allowing the user to access the site at all may be unnecessary and poses a potential security risk through disclosure of the network layer identifier and locator for the resource. Even if the user does have an account with mypage.example.com, some mechanism must still be employed for the user to be identified and authenticated by the website.
Various means exist to authenticate a user that is requesting a resource. In a typical scenario, the user may have login credentials on a website, or a cookie associated with past exchanges of those credentials. The login credentials, once validated, authenticate the user, allowing access to member only or user specific resources. For example, a user visiting a bank's website may login to view information associated with the user's account.
One problem with this type of authentication is that, until the user is authenticated or identified, the resource resolution process typically acts in the same way for every user. Advanced networking mechanisms may be employed on the resource server to filter different types of requests before authentication, such as diverting network traffic based on the geolocation of a user's IP address, e.g., a user in Europe may be diverted to a server based in Europe.
Alone, these techniques are problematic for several reasons. One problem with these techniques is that in every instance the resource IP address (or the network layer identifier and service location identifier) is exposed. This is undesirable because the disclosed nature of the resolved IP address (or network layer identifier or service location identifier) exposes the resource to distributed denial of service (DDoS) attacks, probes of the software of the systems associated with the IP address for security weaknesses, or attempts to gain unauthorized access or control of user accounts or other resources normally accessed at that IP address (or network layer identifier or service location identifier). This situation is akin to, after receiving a knock on the front door, opening the door just a crack to see who is outside. If the person outside is malicious, once you open the door, the person may be able to get in. It would be safer to verify who is standing outside before opening the door, or perhaps not to disclose your home address and what resources may be available there in the first place.
A method and system is desired that can perform adaptive including, but not limited to, authenticated responses to of a DNS requestor prior to returning an IP address (or network layer identifier or service location identifier), to in part ensure that the requestor has authorization to access to the ultimate resource before opening the door or disclosing the address. The following disclosure solves these problems and provides added conveniences and functionality to the name resolution process. For example, as described below, this pre-authentication system allows administrators to prescribe specialized behavior at the DNS level based on the authentication status of the requestor.